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Proposed  Topics 


T  h  e  to  1 1  o  wi  n  g  t  o  p  i  c  s  w  e  r  e  p  r  o  p  o  s  e  d  d  u  ri  n  g  a  b  ra  i  n  st  o  r  m  i  n  g  a  n  d 
consolidation  session. 

1 .  H  o  w  t  o  build  a  s  oft  wa  re  a  re  h  it  e  ct  u  r  e  c  o  rn  rn  u  n  it  y 

■  0  r  g  a  n  i  z  at  i  o  n  a  I  c  o  n  d  it  i  o  n  i  n  g  t  o  a  c  c  e  pt  a  rc  h  it  e  ct  u  r  a  I 
practices 

2.  Gaps  in  the  methods 

■  Tailoring  methods 

■  St  a  n  d  a  r  d  i  z  i  n  g  ATAM ,  v  a  I  u  e  ?  H  o  w  t  o  g  o  a  b  o  ut  it  ? 

■  Ap  plica  bility  (e .  g . ,  e  nt  e  r  p  ri  s  e  a  rc  h  it  e  ct  u  r  e  s) 

■  What  is  prerequisite  knowledge  (Domain  knowledge)  for 
ATAM 

What  to  measure 

4 .  Relationship  of  a  rc  h  it  e  ct  u  r  e  a  n  d  p  ro  c  e  s  s  -  h  o  w  t  o  build 

s y st e m s  (o rg  a n i z  at i o n  a s  a  w h ole  to  mi e  et  Q A  re  q u i  re  rn e  nt s) 

5 .  Wh  at  are  people  doing  wit  h  q  u  a  I  it  y  att  ri  b  ut  e  s  c  e  n  a  ri  o  s 

6 .  Arc h it e ct u  re  re c o  n st ru ct i o  n 

7 .  Arc  h  it  e  ct  u  re  v  i  s  u  a  I  i  z  at  i  o  n 
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Working  Session  Topics 

These  three  topics  were  selected  for  the  working  sessions: 

*  Gaps  in  the  methods 

*  Measurement 

*  Architecture  and  process 
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Gaps  in  the  Methods 

The  charge  to  this  working  session  was  to  discuss  the 
following  topics: 

*  Tailoring  AT  AM 

*  Prerequisite  knowledge  to  performing  an  AT  AM 

*  Standardizing  AT  AM 

*  Applicability  of  AT  AM  to  large  systems,  to  enterprise 
a  rc  h  ite  ctu  re  s ,  t  o  syste m  a  rc  h  ite  ctu  re  s 
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Gaps  in  the  Methods  -  Tailoring  AT AM 

The  attendees  were  happy  with  the  steps  of  AT  AM  but 
made  some  suggestions  for  improving  the  process  of 
c  a  ptu  ring  th  e  re  s  u  Its  .These  we  r  e : 

*  Include  measures  of  the  system  (size,  number  of 

d  i  sti  n  ct  I  o  c  ati  o  n  s  wh  e  re  it  wa  s  b  e  i  n  g  d  e  ve  I  o  p  e  d ,  n  u  rn  b  e  r 
of  d  e  ve  I  o  p  e  rs )  in  the  stati  sti  c  s  ke  pt 

*  InclucJe  foil  o  w  u  p  th  at  q  u  e  sti  o  n  s  re  s  p  o  n  s  e  o  f  d  e  ve  I  o  p  e  r  s 
to  risks.  AT&T  uses  a  phone  conference  3-4  weeks 
afte r  t  h  e  c  o  n  c  I  u  s  i  o  n  o  f  a  re  vi  ew  f o  r  t  h  e  d  e v  e  I  o  p  e  rs  to 

re p o rt  their  a cti o  n s  o n  th  e  s e ri o  u s  r i s ks . 

Th  e  re  w  a  s  a  I  s  o  a  c  o  rn  rn  e  nt  t  h  at  n  oth  i  n  g  s  h  o  u  I  d  b  e  d  o  n  e  t  o 
change  the  AT  AM  from  a  collaborative  exercise  between 
th  e  e  va  I  u  at  o  rs  a  n  d  th  e  p  roj  e  ct  i  nt  o  a  n  a  d  ve  rs  a  r  i  a  I  e  xe  rc  i  s  e . 
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Gaps  in  the  Methods  -  Prerequisite 
knowledge  to  performing  an  AT AM  -1 

Th  e  re  w  a  s  g  e  n  e  r  a  I  a  g  re  e  rn  e  nt  t  h  at  thee  va  I  u  at  i  o  n  te  a  rn 
should  include  expertise  in: 

*  AT  AM 

*  Quality  attributes  of  importance  to  the  system  being 
revi  ewed 

*  Domain  knowledge 

Th  e  re  w  a  s  a  I  s  o  gene  r  a  I  a  g  re  e  rn  e  nt  th  at  n  ot  e  ve  ry  rn  e  rn  b  e  r 
of  the  team  needed  to  know  all  of  these  areas.  Different 
te  a  rn  s  wo  u  I  d  b  e  c  o  n  stit  ute  d  fro  rn  a  rn  o  n  g  th  e  a  va  ilable 
personnels  o  th  at  all  of  th  e  p  re  r  e  q  u  i  s  ite  kn  owl  e  d  g  e  i  s 
represented. 
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Gaps  in  the  Methods  -  Prerequisite 
knowledge  to  performing  an  AT AM  -2 

G a i  ni n  g  th  e  p re r  e q u  i s  ite  kn  owl  e d  g  e  a b □  ut  AT A fvl  c a n  b  e 
d o n e  in  a  v a ri ety  □  f  fa s h i  o n s : 

*  T a  ki  n  g  t  h  e  S  E I  c  o  u  rs  e  s 

*  B  uyi  ri  g  t  h  e  AT  A  M  e  va  I  u  at  i  o  n  b  o  o  k 

*  P  a  rti  c  i  p  a  ti  n  g  i  n  AT  A  M  s  I  e  d  b  y  tr  a  i  n  e  d  e  va  I  u  at  o  rs . 

Th  e  rn  eth  o  d  o  f  e  n  try  b  e  c  o  rn  e  s  a  c  o  st/b  e  n  ef it  q  u  e  sti  o  n . 

T a  ki  n  g  t  h  e  c  o  u  rs  e  s  a  n  d  re  c  e  i  vi  n  g  tr  a  i  n  i  n  g  re  d  u  c  e  s  th  e 
learning  time  and  the  probability  of  errors.  There  is  a  cost 
for  the  courses  however.  Different  members  of  the  group 
who  had  performed  AT  AMs  had  arrived  there  via  different 
routes. 
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Gaps  in  the  Methods  -  Standardizing 
ATAM 

T  h  e  g  r  o  u  p  felt  t  h  at  if  ATAM  h  a  d  s  o  rn  e  s  o  rt  o  f  o  ffi  c  i  a  I  re  c  og  nitio  n , 
it  wo u I d  be c o m e  e as i e r  fo r  t h e m  t o  c o n v i n c e  their  o r g a n i z at i o n s 
t  o  p  e  rf  o  r  rn  ATAM  s .  0  n  e  p  o  s  si  b  1  e  rn  et  h  o  d  t  o  a  c  h  i  e  v  e  o  ffi  c  i  a  I 
re  c  o  g  n  it  i  o  n  wa  s  f  o  r  ATA  M  t  o  b  e  c  o  rn  e  a  n  o  ffi  c  i  a  I  (IEEE  o  r  I S  0) 
standard. 

An  ot  h  e  r  m  et  h  o  d  wa  s  f  o  r  t  h  e  D  o  D  tore  q  u  i  re  ATA  M  s  fo  r  t  h  e  i  r  I  a  rg  e 
c  o  nt  r  a  ct  s .  Th  e  Arm  y  i  s  c  u  rr  e  nt  I  y  p  utt  i  n  g  I  a  n  g  u  a  g  e  in  their  R  E  F  s 
for  AC  AT  I  and  II  programs  that  requires  ATAMs  to  be 
performed. 

Alt  h  o  u  g  h  t  h  e  g  ro  up  felt  t  h  at  h  a  v  i  n  g  a  n  tiffi  c  i  a  I  st  a  n  d  a  r  d  w  o  u  Id  be 
be  neficial ,  no  n  e  o  f  t  h  e  g  ro  u  p  wa  s  wi  1 1  i  n  g  t  o  p  a  rt  i  c  i  pat  e  in 
s tandardization  e fif o rt s . 
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Gaps  in  the  Methods  -  Applicability  of 
AT AM  to  Large  Systems  -1 

T  h  e  a  p  p  I  i  c  a  b  i  I  it  y  o  f  ATAM  tola  rg  e  s  y  st  e  rn  s ,  e  nt  e  r  p  ri  s  e  a  n  d 
s  y  st  e  rn  a  re  h  it  e  ct  u  re  s  introduces  p  ro  b  I  e  rn  s  o  f  seal e  a  n  d  s  c  o  p  e . 

T  h  e  p  r  o  b  I  e  rn  s  o  f  s  c  a  I  e  c  o  rn  e  a  b  o  ut  r  e  g  a  r  d  I  e  s  s  o  f  w  h  et  h  e  r  ATAM 
i  s  a  p p I i  e d  t o  a  s  o  ft  wa  re  a  re  h  it  e  ct  u  re ,  a  s  y  st  e  rn  a  re  h  it  e  ct  u  re ,  o  r  a  n 
enterprise  architecture.  The  scale  problem  comes  about  because 
in  a  I  a  rg  e  s  y  st  e  rn  wit  h  rn  u  It  i  p  I  e  subs  y  st  e  rn  s ,  e  va  I  u  at  i  ri  g  b  ot  h  t  h  e 
i  rit  e  r  a  ct  i  o  n  s  a  rn  o  n  g  t  h  e  s  u  b  s  y  st  e  rn  s  a  n  d  t  h  e  su  b  s  y  st  e  rn  s 
t  h  e  rn  s  e  I v  e  s  i  n  a  sin  g  I  e  ATAM  c  a  u  s  e  s  p  r  o  b  I  e  rn  s  b  e  c  a u s  e  t  h  e 
issues  are  different  for  the  evaluators,  the  stakeholders  are 
d  iff  e  r  e  nt ,  a  n  d  the  i  rn  p  o  rt  a  nt  q  u  a  I  it  y  att  ri  b  ut  e  s  rn  a  y  bed  iff  e  r  e  nt . 

0 n  e  p a  rt i ci p a  nt  in  the  b r e a k o  ut  g r o u  p  said  "t h e  I  a r g e  r  t h e  s y  st e rn , 
t  h  e  rn  o  re  t  h  e  e  v  a  I  u  at  i  o  n  fo  c  u  s  e  s  o  n  rn  a  n  a  g  e  rn  e  nt  rat  h  art  h  a  n  o  n 
the  technical  issues" 
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Gaps  in  the  Methods  -  Applicability  of 
AT AM  to  Large  Systems  -2 

The  problems  of  scope  come  about,  especially,  in  a  system  architectural 
context.  Although  AT  A  M  is  agnostic  with  respect  to  the  quality  attributes 
it  is  used  to  evaluate,  when  examining  system  architectures,  attributes 
such  as  power  consumption,  physical  footprint,  and  physical  environment 
are  important.  The  types  of  expertise  needed  in  the  evaluation  team 
becomes  very  large. 

The  group  recommends  that  scoping  problems  be  dealt  with  in  Phase  0 
and  one  indication  of  the  scope  of  an  evaluation  is  the  operational 
concept.  If  the  system  to  be  evaluated  has  an  operational  concept 
defined  then  the  evaluation  can  concentrate  on  the  scope  of  that  concept 
and  not  delve  too  deeply  into  the  subsystems  included  in  the  scope  or 
too  high  into  the  context  with  in  which  the  scope  exists. 

The  group  also  raised  the  possibility  of  a  series  of  AT  A  Ms  for  very  large 
systems.  One  to  examine  the  interactions  among  the  subsystems 
together  with  others  to  examine  the  subsystems  themselves. 
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Measurement 

The  What  to  Measure  working  session  was  chartered  to 
discuss  the  subject  of  measuring  cost  and  benefit  of 
a  re  h  ite  ctu  re  a  n  d  a  r  c  h  it  e  ctu  re-  c  e  ntri  c  p  r  a  cti  c  e  s .  B  e  c  a  u  s  e 
there  is  a  large  body  of  work  on  measuring  cost,  we 
concentrated  on  benefit. 

F  i  rst ,  we  e  sta  b  I  i  s  h  e  d  th  e  g  r  o  u  n  d  w  o  rk  forthediscu  s  s  i  o  n , 
covering  what  can  be  measured,  why  we  measure,  who 
does  it  and  who  consumes  it,  when  to  measure,  and  how 
to  measure. 
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Measurement  -  What  Can  be 
Measured 

We  can  measure  products  and  artifacts,  or  we  can 
rn  e  a  s  u  re  th  e  a  rc  h  ite  ctu  r  e  p  ro  c  e  s  s .  Arc  h  ite  ctu  r  e-  c  e  ritri  c 
measures  related  to  products  and  artifacts  start  with  the 
q  u  a  I  ity  attri  b  ut  e  s  of  th  e  d  e  p  I  oy  e  d  syste  rn ,  q  u  a  I  ity  a  ttr  i  b  ute  s 
that  the  architecture  is  intended  to  imbue,  such  as  its 
p  e  rf  o  rrn  a  n  c  e  o  r  s  e  c  u  r  ity  o  r  a  va  i  I  a  b  i  I  ity .  S  o  rn  e  q  u  a  I  ity 
attri  b  ute  s  a  re  dire  ct  rn  a  n  if  e  stat  i  o  n  s  o  f  b  u  s  i  n  e  s  s  g  o  a  I  s ,  s  u  c  h 
as  time  to  market,  return  on  investment,  total  cost  of 
ownership,  amount  of  reuse,  success  of  product 
rn  i  g  rati  o  n/e  vo  I  uti  o  n .  P  r  o  c  e  s  s-  r e  I  ate  d  rn  e  a  s  u  re  s  i  ri  c  I  u  d  e 
time  and  productivity  measures,  such  as  amount  of  rework 
or  the  cost  of  particular  activities  such  as  evaluation. 
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Measurement  -  Why  We  Measure 


We  measure  to  track  progress,  to  see  if  we  are  meeting 
goals,  and  to  be  able  to  predict  the  future  based  on  trends. 

I  n  a  n  atm  o  s  p  h  ere  of  a  re  h  ite  ctu  r  e  "  e  v  a  n  g  e  I  i  s  rn , "  we  a  I  s  o 
measure  to  make  a  case  for  arch  ite  ctu  re- centric 
d  ev  e  I  o  p  rn  e  nt  a  n  d  p  ra  cti  c  e  s .  We  m  e  a  s  u  r e  to  f  i  ri  d  a  "  p  o  ste  r 
child"  activity  that  will  make  a  positive  case  for 
architecture- based  development,  to  establish  a  baseline 
for  best  practice  and  collect  lessons  learned. 
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Measurement  —  For  Whom  We 
Measure 


C  o  n  s  u  rn  e  rs  of  rn  e  a  s  u  re  s  i  n  c  I  u  d  e  I  e  a  d  e  rs  h  i  p  a  n  d 

rn  a  n  a  g  e  rn  e  nt ,  f  i  n  a  n  c  i  n  g  a  uth  o  r  iti  e  s ,  s  a  I  e  s  a  n  d  rn  a  rket  i  n  g 

staff ,  a n d  th e  engineerin g  d e p a rtrn e nts . 
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Measurement  -  When  Do  We  Measure 


Here,  the  que sti o n  i s  h o w  e a rl y  c a n  we  m e a s u re . 
Discussionhe  re  wa  s  a  b  b  re  vi  at  e  d  a  n  d  r  e  a  c  h  e  d  n  o 
conclusions. 
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Measurement  -  How  to  Measure 


Here,  the  cl i s c u s s i o n  q u i c kl y  a rr iv e d  at  th e  con c I u s i o n  th a t 
h o w  (and  wh a t  a n d  wh e n )  we  m e a s u re  s h o u I d  b e  tailored 
for  producing  the  results  useful  to  the  stakeholders  who 
n  e  e  d  th  e  m .  A I  s  o ,  b  e  c  a  u  s  emea  s  u  re  m  e  nt  c  a  n  be  a  c  o  stly 
a ctivity ,  onl y  those  rn e a s u re s  n e c e s s a ry  s h o  u I d  b e 
collected. 
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Measurement  -  Benefits  of 
Architecture 

Wh at  a r  e  t h  e  b  e  n  e  fit  s  of  s  o  ft  wa  re  a  re  h  it  e  ct  u  re  t  h  at  w  e  s  h  o  u  I  d 
expe  ct  t  o  r  e  v  e  a  1 1  h  ro  u  g  h  rn  e  a  s  u  re  rn  e  nt  ?  We  b  rain  st  o  rrn  e  d  a 
short  list  of  b  e  n  e  fit  s ,  wit  h  e  a  c  h  p  re  ceded  by  the  st  a  k  e  h  o  I  d  e  r  w  h  o 
would  expect  to  see  it: 

■  M  a  rk  et  i  ng:  I  nt  e  ro  p  e  ra  bi  lit  y 

■  M  a  n  a  g  e  m  e  nt :  P  ro  d  u  ct  i  v  it  y 

■  C  T  0 :  N  u  rn  b  e  r  o  f  a  n  g  ry  v  o  i  c  e  rn  ails  fr  o  rn  C  E  0 

■  P  ro  duct  rn  a  n  a  g  e  r:  Nu  m  b  e  r  o  f  call  s  at  s  e  rv  ice  center 

■  Va  ri  o  u  s :  N  e  w  m  i  s  s  i  o  n  c  a  p  a  b  i  I  it  y  i  n  s  h  o  rt  t  i  rn  e 

■  C  E  0 ,  M  a  rk  et  i  r ig : :  Re  v  e  n  ue ;  alio  ws  p  ri  c  e  t  a  rg  et  t  o  be  m  et 

■  Marketing,  CTO::  Product/feature  diversity 

■  CEO:  :  Enabling  strategic  direction  (e.g.  globalize) 

*  C  0  0 ,  rn  a  n  a  ge  m  e  nt :  I  n  c  r  e  a  s  i  n  g  o  rg  a  n  i  z  at  i  o  n  a  I  k  n  o  wl  e  d  g  e 

■  P  ro  duct  rn  a  na  g  e  r:  St  able  wit  h  r  e  s  pi"  e  ct  t  o  n  e  w  t  e  c  h  n  o  I  o  gy 

■  Marketing:  Total  cost  of  ownership  vs.  time  to  market 

■  C x 0 :  L o n  g  t e rrn  p r o d  u ct i vit y  a n  d  efTici  e n c y 
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Software  Engineering  Institute 


Measurement  -  Benefits  of 
Architecture  Activities  -1 

F  i  n  a  1 1  y ,  the  g  r  o  upturned  its  att  enti  o  n  t  o  h  o  w  t  o  rn  e  a  s  u  re  t  h  e 
benefits  imbued  by  specific  architecture-related  activities. 

F o r  a n  ATAM -based  arc h it e ct u r e  e v al uati on ,  w e  realized  that 
t  h  ere  a  re  t w  o  kinds  o  f  ri  s  k  s  u  n  c  o  v  e  r  e  d :  ri  s  k  s  t  h  at  w  e  r  e 
p  r  e  vi  o  u  s  I  y  k  n  o  w  n ,  a  n  d  ri  s  k  s  t  h  at  we  re  p  r  e  vi  o  u  sly  u  n  k  n  o  w  n . 
However,  even  if  a  risk  is  known,  it  is  not  necessarily  the  case 
t  h  at  it  wo  u  I  d  ha  v  e  been  a  ct  e  d  o  n .  0  n  e  b  e  n  e  fit  of  a  n  ATAM 
evaluation  exercise  is  that  it  elevates  risks  (even  if  previously 
k  n  o  wn  t  o  the  tec  h  n  i  c  a  I  st  aft)  tot  h  e  att  e  nt  i  o  n  of  rn  a  n  a  g  e  rn  e  nt , 
wh  o  c  a  n  t  h  e  n  all  o  c  at  e  d  re  s  o  u  rc  e  s  a  n  d  ro  o  rn  i  n  t  h  e  scheduleto 
address  them. 
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Measurement  -  Benefits  of 
Architecture  Activities  -2 

We  reasoned  that  the  expected  benefit  of  an  AT  AM 
exercise  can  be  expressed  as  follows: 

SUM[i=1  ,n]  [  (  cost  of  risk- 1 )  x  (  probability  of  risk- 1 )  ]  - 
( c  o  st  of  p  e  rfo  rrn  i  n  g  th  e  e  va  I  u  at  i  o  n ) 

where  the  risks  are  those  uncovered  by  the  evaluation  that 
wo  u  I  d  n  ot  h  a  ve  been  a  cte  d  o  n  wit  h  o  ut  thee  xe  rc  i  s  e .  Th  i  s 
is  a  minimum  benefit,  because  it  does  not  take  into 
a  c  c  o  u  nt  th  e  intangible  b  e  n  e  fits  s  u  c  h  a  s  i  n  c  re  a  s  e  d 
sta  ke  h  o  I  d  e  r  c  o  rn  rn  u  n  i  c  ati  o  n  a  n  d  i  rn  p  ro  ve  d  d  o  c  u  rn  e  nt  ati  o  n . 
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Software  Etigiuering  Insti  lule 

Measurement  -  Benefits  of 
Architecture  Activities  -3 

We  th e  n  tu rn  e  d  o u  r  atte  nti  o  n  to  th  e  b e n elit  of  a  roh  ite  otu  re  d o cum  e  ntati  o  n .  Afte  r 
brainstorming  a  list  of  reasons  why  documentation  should  be  beneficial,  the  group 
crafted  the  following  expression  to  quantify  this  benetitfll: 

2  [i=1,  n]  •[  delta  (cost  of  some  activity)  I  }  -  (cost  of  documentation) 

Activiti  es  i  n  cl  u  d  e  th  in  gs  I  ike  co ding,  a  n  alysis,  p  ro  j  e  ot  mi  a  n  a  ge  m  e  nt  p  I  an  ni  n  g , 
maintenance,  making  changes,  performing  downstream  design,  testing,  and  the 
I  ike .  T  he  d  elta  ref  e  rs  to  th  e  cost  of  p  e  rf o  rm  i  n  g  th  at  a  ctivity  with  o  ut  do  cu  mi  e  ntati  on 
mi  i  n  us  th  e  cost  of  p  e  rf o  rm  i  n  g  that  sa  m  e  a  ctivity  with  d  o  cu  m  entati  on.  P  resu  mi  a  b  ly 
th  e  cost  of  ca  rryi  n  g  o  ut  th  ese  a  ctiviti  es  with  d  o  cu  mi  e  ntati  o  n  wi  libel  owe  r.  (F  o  r 
activities  that  are  not  affected  by  having  documentation,  the  delta  is  zero,  and  so 
these  do  not  contribute  to  the  benefit  equation.) 

The  group  suspected  that  this  expression  was,  in  fact,  easily  generalized  to  quantify 
the  benefit  of  any  architecture- related  activity.  We  hypothesize  that  the  benefit  of 
such  an  activity  is  whatever  cost  reduction  in  subsequent  activities  as  a  result, 
m  i  n  us  th  e  cost  of  th  e  a  ctivity  i  n  th  e  fi  rst  p  I  a  ce . 

[11  The  group  originally  added  a  term  to  this  expression  to  count  the  "avoided  cost 
of  poor  q  u  al  ity"  to  th  e  b  e  nef  it  of  d  o  cu  me  ntati  on.  H  o  weve  r.  su  b  se  q  u  e  nt 
consideration  suggested  that  this  avoided  cost  is  captured  in  the  reduced  cost  of 
subsequent  activities. 
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Architecture  and  Process 

T  h  i  s  w  o  rk  i  n  g  s  e  s  s  i  o  n  wa  s  c  h  a  rt  e  re  d  to  d  i  s  c  u  s  s  the  r  el  at  i  o  n  s  h  i  p 
b et we e n  a rc h it e ct u re  and  p r o c ess  i n  t h e  c o nt ext  of  h o w  to  build 
s  y  st  e  rn  s  a  n  d  h  ow  the  o  rg  a  n  i  z  at  i  o  n  a  s  a  wh  o  I  e  rn  e  et  s  q  u  a  I  it  y 
attribute  requirements. 

S  o  rn  e  i  n  it  i  a  I  q  uesti  o  n  s  we  re  raise  d  to  e  st  a  b  I  i  s  h  t  h  e  g  r  o  u  n  d  wo  rk 
for  the  discussion: 

■  What  processes  are  relevant? 

■  I  s  t  h  e  re  a  re  fe  re  n  c  e  fr  a  rn  e  w  o  rk  t  h  at  p  e  o  pie  u  s  e  ? 

■  On  which  processes  does  organizational  context  exist? 

■  H o w  d o  w e  c o p e  wit h  p r o c essesthat  don't  ha v e  a n 
architecture  focus? 

■  Are  q  u  a  I  it  y  r  e  q  uir  e  rn  e  nt  s  sol  v  e  d  i  n  t  h  e  a  rc  h  it  e  ct  u  re  o  r 
wit  hint  h  e  o  rg  a  n  i  z  at  i  o  n  o  r  b  ot  h  ?  H  ow  a  r  e  t  h  es  e  a  I  i  g  n  e  d  ? 
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Architecture  and  Process  -  Common 
Models 

*  F ew  o rg  an i z at i o n  s  u s e  a  p re  d  ef  i n  e  d  fra rn e wo r k  -the y 
are  building  their  own 

*  For  th e  s  a ke  of  a r g  u rn e nt ,  c  o u I  d  n 't  s o rn ethi  n  g  I i  ke  th  e 

Z  a  c  h  rn  a  n  fra  rn  e  wo  r  k  b  e  u  s  e  d  a  s  th  e  c  o  rn  rn  o  n  I  a  n  g  u  a  g  e 
o  r  m  o  d  e  I  f  o  r  a  re  h  ite  ctu  re  a  n  d  p  ro  c  ess.  It  h  a  s  th  e  rn  o  st 
complete  list  of  "stuff"  and  could  be  used  to  set  the 
ro  a  d  m  a  p  f  o  r  a  n  o  rg  a  n  i  z  at  i  o  n . 

*  There  are  many  forces  that  impact  the  architecture, 
some  are  not  quantifiable,  e.g.,  none  of  the  frameworks 
h a v e  a  cell  th  at  i  n c I u d  e s  p o i  iti c s  a n d  m o n ey . 
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Software  Engineering  Institute 

Architecture  and  Process  -  Process 
Models  -1 

*  Cultural  differences  between  architecture  and  process 
is  one  of  the  biggest  problems  -  often  there  is  a  lack  of 
c  o  rn  rn  u  n  i  c  ati  o  n  in  etwe  e  n  th  e  v  a ri  o  u  s  g  ro  u  p  s 

*  There  is  no  link  between  CM  Ml  and  architecture  -  the 

p  e  o  p  I  e  i  nv  o  I  ve  d  a  re  i  n  d  iff  e  r  e  nt  p  a  rts  of  the  o  rg  a  n  i  z  ati  o n 

*  Bosch  exp  e  r  i  e  n  c  e  h  a  d  s  e  p  a  r a  te  r o  1 1  o  ut  of  p  ro  d  u  ct  line 
a  n  d  p  ro  c  e  s  s  i  rn  p  rove  rn  e  nt  -  a  Ith  o  u  g  h  th  e  re  wa  s  s  o  rn  e 
c ro s s-f e rtiliz ati o  n  b etw e e n  th e  two  g r o u p s  b y  i  n c I u d i  n g 
architecture  staff  in  the  process  group  and  vice  versa. 

*  Software,  system,  and  enterprise  are  inter- related  and 
wi  II  be  p  a  rt  of  a  n  y  d  i  s  c  u  ssiononthe  re  I  ati  o  n  s  h  i  p  of 

a  rc  h  ite  ctu  re  a  n  d  p  r o  c  ess. 
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Software  Engineering  Institute 

Architecture  and  Process  -  Process 
Models  -2 

*  Participants  would  like  to  see  the  SEI  take  the  initiative 
a  n  d  m  e  rg  e  p  r o  c  e  s  s  a  n  d  a  re  h  it  e  ctu  re  —  i  n  d  u  stry  wo  u  I  d 
be  willing  to  pick  it  up  from  there 

*  S o rn e o n e  s u g ge ste d  sta rti n g  wit h  ta i I o r i n g  a  I i g h t- we i g ht 
AT  A  M  i  n  a  S  M  E  ( s  rn  a  1 1  to  me  d  i  u  rn  e  rite  r  p  rise)  p  ro  cess. 

*  CM  Ml  is  more  descriptive  (what  to  do)  -architecture  is 
more  prescriptive  (howto  do  it) 

*  IEEE  Std  14,  j- 2000  (IEEE  Recommended  Practice  for 
Arc  h  it  e  ctu  r  a  I  D  e  s  c  ri  pti  o  n  of  S  oftwa  re- 1  rite  n  s  i  ve 
Systems)  tries  to  do  this  but  is  not  being  used 

*  Quality  attributes  are  identified  by  the  architecture  and 
need  to  be  i n c o rp o ra te d  w ith i n  CM M I  -  C M M I  d o e s  n ot 
give  you  any  help  to  go  from  Business  goals  to 
processes  -  in  the  architecture  there  is  a  process  for 
doing  this 
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Architecture  and  Process  -  Architect’s 
Role  and  Authority 

*  D o D  h a s  p o I i cy  o f  p ro c e d u re .  D e s i re  to  el ev ate 
syste rn s  e n g in  e  e ri n  g  ( i  n c I  u  d ess  oftwa  r  e  a rc h it  e ctu  re 
re vi  e w)  to  s  a  rn  e  i  rn  p  o  rta  n  c  e  a  s  c  o  stands  c  h  e  d  u  I  e . 
Provides  method  for  system/software  architect  to  have 
more  influence  on  process 

*  Eve  n  w  hen  p  o  I  i  c  i  e  s  a  re  i  n  p  I  a  c  e ,  p  r o  j  e  cts  a  re  s  c  h  e  d  u  I  e 
driven. 

*  Tension  between  person  driving  schedule  and  architect 

*  Architecture  is  part  of  quality  and  should  be  part  of 
p  ro  c  ess.  C  u  rr e  ntl  y  th  e  re  i  s  a  d  i  s  c  o  n  n  e  ct 
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Architecture  and  Process  -  Adoption 


*  Need  simple  assurance  scheme 

-  Stakeholder  buy  in 

-  Technical  feasibility 

-  Te  st  c  a  s  e  s  a  I  o  n  g  the  I  i  n  e  s  of  t  h  e  d  e  s  i  g  n 

*  An  a  I  o  gy  to  e  xe  rc  ise ,  d  esire  for  si  I  v  er  bullet,  p  e  o  pie  in 
denial,  e  d  u  cation  p  r  o  c  e  s  s 

*  Perception  -  architecture  take  more  time  to  do  good 
syste  mengineering.  Y  e  s  it  d  o  e  s  -  b  ut  rew  o  rk  i  s 
costlier. 

*  Move  from  awareness  to  commitment  to  architecture 
i  rn  p  rove rn  e  nt  ( d  o  c  u  m  e  n  tati  o  n ,  etc . ) 

*  Need  a  champion  within  the  organization  -  with  some 
clout 
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Architecture  and  Process  -  Standards 


*  Industry  depends  on  research  organizations.  Need 

c  i  e  a  r  f o  c  u  s  o  n  w  h  at  n  e  e  d  to  b  e  d  o  n  e .  M  a  k  i  n  g  rn  et  h  o  d  s 
a  "  sta  n  d  a  r  d " .  D  i  s  c  o  n  n  e  ct  b  etw  e  e  n  a  rc  h  ite  ct ,  S  E  P  G , 
p  roj  e  ct  rn  a  n  a  g  e  rn  e  n  t .  O  p  p  o  rtu  n  ity  f  o  r  re  sea  rc  h 
o  rg  a  n  i  z  ati  o  n  s  to  ta  ke  a  I  e  a  d  e  rs  h  i  p  r  o  I  e  to  e  sta  b  I  i  s  h 
standard. 

*  Government  model  -  "standard"  could  be  stating  what 
needs  to  be  done  without  necessarily  saying  how. 

D  iff e  re  rit  d  o m  a  i  n  s  h  a  ve  d  iff  e  re  nt  d  ri  ve  rs .  D  e  p  e  n  d  e  nt  o n 
buyer -smartness  on  what  is  needed  in  terms  of  life 
cycle  view 
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Software  Engineering  Institute 

Architecture  and  Process  -  ROI 


*  Source  selection  often  does  not  reward  innovation  but 
takes  conventional  approach  (appears  less  riskier). 

S  i  g  n  i  f  i  c  a  nt  R  O I  i  s  n  e  e  d  e  d  t  o  o  ve  rc  o  m  e  ri  s  k 

*  VVh  at  i  s  th  e  t  h  re  s  h  o  I  d  f o  r  R  O I  f  o  r  wh  i  c  h  a  n  o  r  g  a  n  i  z  ati  o  n 
will  accept  a  project? 

*  Short-term  vs.  long  term  focus 
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